11
(Gp:) Emisor
(Gp:) Receptor
(Gp:) Buffer
Arquitectura
Productor/Consumidor
12
Objetivos de la AS
Comprender y manejar la estructura de las aplicaciones complejas
Reutilizar dicha estructura (o parte de ella)
Planificar la evolución de la aplicación
Analizar la corrección de la aplicación y su grado de cumplimiento frente a los requisitos iniciales
Permitir el estudio de propiedades específicas
13
Ventajas de las A.S.
Resaltan aquellos aspectos estucturalmente importantes, tanto funcionales como no funcionales
Eliminan muchos riesgos y errores de diseño, desarrollo e implantación
Permiten un desarrollo paralelo, aumentando la productividad
14
El “territorio” de las AS
15
Modelo, Vista y Punto de Vista
Modelo (model)
Una descripción completa de un sistema a un determinado nivel de abstracción
Vista (view)
Una proyección de un modelo desde una perspectiva
Omite las entidades y elementos que no son relevantes
Punto de vista (viewpoint)
La definición (o descripción) de una vista
Prescribe su contenido, significado y representación
16
Niveles de Abstracción
Estilos arquitectónicos
familias de sistemas que siguen el mismo patrón estructural
Modelos y arquitecturas de referencia
particularizan un estilo y definen los conceptos asociados
Marcos de Trabajo
arquitectura reutilizable en aplicaciones de un mismo dominio
Familias y líneas de productos
arquitectura de una aplicación con diferentes configuraciones
Instancias
arquitectura de una aplicación concreta
17
Estilos Arquitectónicos
Componentes
unidades computacionales y de datos
Conectores
mecanismos de interacción entre componentes
Patrones y restricciones de interconexión
invariantes del estilo
Mecanismos de control
coordinación entre componentes
Propiedades
ventajas e inconvenientes
18
Clasificación de estilos
Sistemas de flujo de datos
Sistemas basados en llamada y retorno
Sistemas de componentes independientes
Sistemas centrados en los datos
Máquinas virtuales
Sistemas heterogéneos
19
Estilos y subestilos (I)
Sistemas de flujo de datos
Sucesión de transformaciones de los datos de entrada
Subestilos: pipe & filter y procesamiento por lotes
Sistemas basados en llamada y retorno
Reflejan la estructura del lenguaje de programación
Subestilos: programa principal-subrutina, OO, capas
Sistemas de componentes independientes
Componentes distribuidos que se comunican por paso de mensajes
Subestilos: sistemas cliente/servidor y de eventos
20
Estilos y subestilos (II)
Sistemas centrados en los datos
Acceso compartido a un banco de datos central
Subestilos: repositorio y pizarras (blackboards)
Máquinas virtuales
Simulan una funcionalidad no nativa del entorno
Subestilos: intérpretes y sistemas basados en reglas
Sistemas heterogéneos
Localmente, jerárquicamente o simultáneamente heterogéneos
21
Descripción de Arquitecturas
Diagramas informales de cajas y líneas
Imprecisos, ambiguos y no analizables
Lenguajes de programación modular
Mezclan aspectos de programación y estructurales
El análisis se basa en emparejamiento de nombres
Lenguajes de interconexión de módulos (MILs o IDLs)
Implican un determinado mecanismo de interacción
UML como notación arquitectónica
Lenguajes de Descripción de Arquitectura (LDAs)
22
Lenguajes de Descripción de Arquitecturas (LDAs)
Un LDA es un lenguaje o notación para describir una arquitectura software:
Descripción de componentes, conectores y enlaces entre ellos.
Herramientas para la verificación de la arquitectura y el prototipado rápido.
Existen LDAs de propósito general y otros de dominio específico (DSLs)
23
(Gp:) Sender
(Gp:) Receiver
(Gp:) Buffer
(Gp:) Arquitectura
Productor/Consumidor
(Gp:) Enlaces puertos/roles ¿ analizables ?
(Gp:) Puertos: describen el comportamiento de las componentes
(Gp:) writer
(Gp:) storage
(Gp:) reader
(Gp:) retrieval
(Gp:) Roles: describen el comportamiento de los conectores
24
Requisitos de un ADL
Composición
Debe describir el sistema como una composición de partes
Configuración
Debe describir la arquitectura independientemente de los componentes
Abstracción
Debe describir los roles abstractos que juegan los componentes
Reutilización
Debe permitir reutilizar componentes, conectores, y arquitecturas
Heterogeneidad
Debe permitir combinar descripciones heterogéneas
Análisis
Debe permitir diversas formas de análisis de la arquitectura
25
Ejemplos de LDAs
Ejemplos:
UNICON (Shaw et al. 1995)
Rapide (Luckham et al. 1995)
Darwin (Magee y Kramer, 1996; 1999)
Wright (Allen y Garlan, 1997; 1998)
Executable Connectors (Ducasse y Richner, 1997)
Problema: No cubren todo el ciclo de vida de las aplicaciones software (sólo diseño preliminar), no llegan a la implementación
26
Ejemplos de LDAs : UNICON
Una pipe de Unix
connector Unix-pipe
protocol is
type pipe
role source is Source
MaxConns(1)
end source
role sink is Sink
MaxConns(1)
end sink
end protocol
…
implementation is
builtin
end implementation
end Unix-Pipe
27
Ejemplos de LDAs : Wright
Una pipe de Unix
connector Pipe =
role WRITER = write ? WRITER ? close ? ?
role READER = let ExitOnly = close ??
in let DoRead = (read ? READER ? readEoF ? ExitOnly
in DoRead ? ExitOnly
glue = let ReadOnly = READER.read ? readOnly
? READER.readEoF ? READER.close ??
? READER.close ??
in let WriteOnly = WRITER.write ? WriteOnly ? WRITER.close??
in WRITER.write ? glue ? READER.read ? glue
? WRITE.close ? ReadOnly ? READER.close ? WriteOnly
28
Ejemplos de LDAs : RAPIDE
type Application is interface
extern action Receive(p:params); // evento de entrada
public action Results(p:params); // evento de salida
behaviour
(?M in String) Receive(?M) => Results(?M); // transición de eventos
end Application;
architecture DistrApp(Num: Integer) return InterfaceDistrApp is
P : array(Integer) of Application;
Q: array(Integer) of Resource; //Dual of Application
connect
for i:Integer in 1..Num generate
(?M in String) P(i). Receive(?M) to Q(i).Results(?M);
P(i).Results(?M) to Q(i). Receive(?M);
end generate;
end DistrApp;
29
Ejemplos de LDAs : Darwin
(Gp:) entrada
(Gp:) cabeza : Filtro
(Gp:) ant
(Gp:) salida
(Gp:) salida
(Gp:) : Pipeline
(Gp:) entrada
(Gp:) salida
(Gp:) cauce : Pipeline
(Gp:) sig
30
LDAs del grupo GISUM
LDC + LDS (Fuentes y Troya, 1998)
Modelo de componentes pasivos y conectores reactivos
Formalismo de especificación de comportamiento de conectores (TDFs, ?-cálculo, etc.)
LEDA (Canal, Pimentel y Troya, 2000)
Basado en el álgebra de procesos ?-cálculo
Permite especificar arquitecturas dinámicas
 Página anterior | Volver al principio del trabajo | Página siguiente  |